Large software applications are often composed of unmanageably large amounts of executable code. In order to facilitate creation and management of large software systems, then, the systems are often composed of many different components, including some components called business objects. Business objects are software components that may encompass user interfaces, data, business rules, communication components and any other code that may relate to their function.
In order to simplify design of these large systems, business objects are often defined as collections of logically related functions and data. A large application designed to facilitate a typical mail order business, for example, may have many different business objects. An ordering business object may be used to handle incoming orders or changes to existing orders. A shipping business object may be implemented to handle all shipping related tasks, such as arranging for deliveries or determining shipping times and costs. Business objects may handle some tasks independently while communicating with other business objects to complete other tasks.
This design model suffers from several problems however. Storing many different components all in one business object may make operation slower. Whenever one part of the business object is acting, the others may be suspended until that action is complete. Thus, if one business object communicates with another business object in order to perform a coordinated action, both business objects will be locked until that operation is complete. Users would be unable to use the objects, nor would other business objects be able to communicate with them, until the operations were completed.
When integrating business objects together, a user encounters another severe deficiency of the present state of the art. A business object cannot be designed to coordinate with every imaginable other business object, and thus some changes will have to be made to one or both of the newly integrated business objects in order to coordinate their operations. As discussed above, this leads to a shutdown and upgrade of at least one of the business objects, as well as a review of the entire inner working of the business objects in order to learn which components within them must be changed. Furthermore, changes to one business object may necessitate changes to its interface, so that all integrated business objects must be updated at the same time to account for the one new interface in the system.
Accordingly, there is a need in the art for a system that separates business objects from their frequently modified or accessed components. There is also a need for such a system to allow business objects to be integrated with other business objects or interfaces that are not known when the business objects are designed.